@mikerreed @chris-rive we were discussing this a while ago

@chris-rive maybe you can take a look at whether there's a configuration flag or something that can enable variable-length arrays in MSBuild? This has bitten us before and it kind of sucks to have to resort to allocating them on the heap every time (Mike mentioned Skia has a cool abstraction that allocated on the stack and grows to the heap only if necessary that maybe we should adopt).

MSVC has _alloca and _malloca for stack allocation. I'm guessing that's what the abstraction layer would resort to.

whether there's a configuration flag or something that can enable variable-length arrays in MSBuild?

If you install Visual Studio with Clang tools, you can use LLVM as your platform toolset instead of MSVC. I wonder if this would allow us to use variable length arrays and other Clang features?

Using GN on Skia we were able to build entirely with Ninja/Clang, and just set up a custom build command for working inside Visual Studio. I would love it if we could do that here as well. Clang has much better support for SIMD, whether that's SSE, NEON, or WASM, so I would really push for us to drop MSVC support and instead focus on figuring out how to use Clang everywhere.

Skia has a cool abstraction that allocated on the stack and grows to the heap only if necessary that maybe we should adopt

I think we could accomplish the same thing using a custom allocator with std::vector, which would be more "standard" and future proof, I believe. I like the concept and think we will probably want it, even if we also get in support for variable length arrays.

Clang has much better support for SIMD, whether that's SSE, NEON, or WASM, so I would really push for us to drop MSVC support and instead focus on figuring out how to use Clang everywhere.

I can confirm that the codebase compiles out-of-the-box with clang-cl using visual studio. The command line options work, and VLAs are fine. There are about a million warnings, but I get a rive.lib at the end of it.
EDIT: I tell a lie. The command line options -fno-exceptions and -fno-rtti are still ignored by clang-cl (-Wunknown-argument). But I still get a lib.

I ran premake5 vs2019 and then loaded the solution file in visual studio and made a few changes to the options, including selecting clang-cl as the toolset.

The warnings are a symptom of the -Wall flag. I've found out it is recommended to use -W4 instead with clang otherwise every other line gives you a "Not compatible with c++98" warning :(

So if you are thinking of ditching MSVC support, I'm happy to close this PR? Otherwise I can suggest an alternative that uses _malloca (docs). This function attempts to allocate via stack, and if not possible, uses heap instead.

@luigi-rosso Is the 'official' ( 😁 ) support on windows for clang-cl and not MSVC?
If so, I will close this PR.